I think it would be preferrable to have all config-related constants on one place (although splitting settings.rs is not a bad idea), unless they were used only in this module

Though I disagree about placement to settings.rs as the idea is to make agency_comm standalone, thanks to your comment I've noticed that these things actually do not need to be static at all. These are only used within set_testing_defaults_agency function in agency_settings.rs, so I am moving it right there.

I didn't say anything about putting to settings.rs, by one place I mean e.g. two submodules of a single module. I see your point about benefits of making agency-related logic standalone, but these configs are going to be used throughout libvcx even in case agency_comm were to become separate crate, they are part of the interface between libvcx and agency_comm, and thus are global to the app in that sense.

Well, these particular here are default values used in agency tests, and as I've found, really just local to 1 single test.

By "config-related constants" I meant the config keys as well. But if the plan is to get rid of agency_settings.rs anyways (which I agree with), let's keep it as it is for now.

I wonder why is skip_serializing_if necessary?

Well, I haven't done modifications here, just moved the datastructure, however I suppose it makes sense to skip serializing the field if there's no value set.

But why is it necessary? Extra fields are ignored during deserialization...

Not ignored

use serde_json;

#[derive(Serialize)]
struct Data {
    #[serde(skip_serializing_if = "Option::is_none")]
    b: Option<String>,
    c: Option<String>,
}

pub fn run()
{
    let data = Data { b: None, c:None};
    let serialized = serde_json::to_string(&data).unwrap();
    println!("serialized={}", serialized);
}

serialized={"c":null}

I said "deserialization", not "serialization" :) I was just wondering if there is any actual functional reason why these specific field must be skipped if none, but I guess this is just a sporadic attempt to reduce the payload size...

One of the reasons all settings should share a module, IMO

Disagree, this "redirection" is to simply preserve aries-vcx functionality as a whole, but removing dependencies on aries-vcx globals is precondition to create independent modules.

What do you mean by redirection? I think that on the contrary, libvcx, as a "user" of agency_comm, has the responsibility of configuring it as necessary. As I see it, agency_settingsis a subset of libvcx settings, not separate from it.

By redirection I meant that call into the src/settings.rs further calls agency_settings.rs.

But yeah, it could be removed and code in all places would have to make calls into agency_settings.rs manually when needed. It was more convenient to implement this way, with "the redirection", but I also don't see this as ultimate state. I think we could eliminate agency_settings.rs completely in the next steps.